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Abstract 

Autonomic management can improve the QoS provided by parallel/ 
distributed applications. Within the CoreGRID Component Model, the 
autonomic management is tailored to the automatic - monitoring-driven 
- alteration of the component assembly and, therefore, is defined as the 
effect of (distributed) management code. 

This work yields a semantics based on hypergraph rewriting suitable 
to model the dynamic evolution and non-functional aspects of Service 
Oriented Architectures and component-based autonomic applications. In 
this regard, our main goal is to provide a formal description of adaptation 
operations that are typically only informally specified. We contend that 
our approach makes easier to raise the level of abstraction of management 
code in autonomic and adaptive applications. 

1 Introduction 

Developers of grid applications cannot rely neither on fixed target platforms 
nor on stability of their status [9]. This makes dynamic adaptivity of appli- 
cations an essential feature in order to achieve user-defined levels of Quality 
of Service (QoS). In this regard, component technology has gained increased 
impetus in the grid community for its ability to provide a clear separation of 
concerns between application logic and QoS-driven adaptation, which can also 
be achieved autonomically. As an example, GCM (the Grid Component Model 
defined within the CoreGRID NoE) is a hierarchical component model explicitly 
designed to support component-based autonomic applications in highly dynamic 
and heterogeneous distributed platforms [4]. 

An assembly of components may be naturally modeled as a graph and, if 
components are autonomic, the graph can vary along with the program exe- 
cution and may change according to input data and/or grid hardware status. 
These changes can be encoded as reaction rules within the component Auto- 
nomic Manager (hereafter denoted as AM). A proper encoding of these rules 
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effectively realises the management policy, which can be specific of a given as- 
sembly or pre-defined for parametric assemblies (such as behavioural skeletons) 
[1, 2]. In any case, the management plan relies on the reconfiguration operation 
exposed by the component model run-time support. 

A major weakness of current component models (including GCM) is that 
the semantics of these operations are informally specified, thus making hard to 
reason about QoS-related management of components. In this work 

• We discuss few primitives useful for component adaptation; the chosen 
operations are able to capture typical adaptation patterns in parallel/ 
distributed application on top of the grid. These are presented as non- 
functional interfaces of components that trigger component assembly adap- 
tation. 

• We detail a semantics for these operations based on hypergraph rewrit- 
ing suitable for the description of component concurrent semantics and 
assembly evolution along adaptations. 

The key idea of our semantical model consists in modeling component-based 
applications by means of hypergraphs which generalise usual graphs be allowing 
hyperedges, namely arcs that can connect more than two nodes. Intuitively, 
hyperedges represent components able to interact through ports represented 
by nodes of hypergraphs. The Synchronized Hyperedge Replacement (SHR) 
model specifies how hypergraphs are rewritten according to a set of productions. 
Basically, rewritings represent adaptation of applications possibly triggered by 
the underlying grid middleware events (or by the applications themselves). 

SHR has been shown suitable for modelling non-functional aspects of service 
oriented computing [6, 7] and is one of the modelling and theoretical tools of 
the Sensoria project [14]. For simplicity, we consider a simplified version of 
SHR where node fusions is limited and restriction is not considered. Even if, for 
the sake of simpleness, the SHR framework used in this work is not the most 
general available, it is sufficient to give semantics to the management primitives 
(aka adaptation operations) addressed here. The autonomic manager - by way 
of these adaptation operations - can structurally reconfigure an application to 
pursue the (statically or dynamically specified) user intentions in terms of QoS. 

2 Autonomic Components and GCM 

Autonomic systems enables dynamically defined adaptation by allowing adapta- 
tions, in the form of code, scripts or rules, to be added, removed or modified at 
run-time. These systems typically rely on a clear separation of concerns between 
adaptation and application logic [10]. An autonomic component will typically 
consist of one or more managed components coupled with a single autonomic 
manager that controls them. To pursue its goal, the manager may trigger an 
adaptation of the managed components to react to a run-time change of appli- 
cation QoS requirements or to the platform status. In this regard, an assembly 
of self-managed components implements, via their managers, a distributed al- 
gorithm that manages the entire application. 



2 



The idea of autonomic management of parallel/distributcd/grid applications 
is present in several programming frameworks, although in different flavours: 
ASSIST [15, 2], AutoMate [13], SAFRAN [5], and GCM [4] all include autonomic 
management features. The latter two are derived from a common ancestor, i.e. 
the Fractal hierarchical component model [12]. All the named frameworks, 
except SAFRAN, are targeted to distributed applications on grids. 

GCM builds on the Fractal component model [12] and exhibits three promi- 
nent features: hierarchical composition, collective interactions and autonomic 
management. GCM components have two kinds of interfaces: functional and 
non-functional ones. The functional interfaces host all those ports concerned 
with implementation of the functional features of the component. The non- 
functional interfaces host all those ports needed to support the component 
management activity in the implementation of the non-functional features, i.e. 
all those features contributing to the efficiency of the component in obtaining 
the expected (functional) results but not directly involved in result computa- 
tion. Each GCM component therefore contains an AM, interacting with other 
managers in other components via the component non-functional interfaces. 
The AM implements the autonomic cycle via a simple program based on reac- 
tive rules. These rules are typically specified as a collection of when- event-lf- 
cond-then- adapt-op clauses, where event is raised by the monitoring of compo- 
nent internal or external activity (e.g. the component server interface received 
a request, and the platform running a component exceeded a threshold load, 
respectively); cond is an expression over component internal attributes (e.g. 
component life-cycle status); adapLop represents an adaptation operation (e.g. 
create, destroy a component, wire, unwire components, notify events to another 
component's manager) [5]. 

We informally describe some common adaptation operations that may be 
assigned to configuration interfaces are the following: 

Migration A component is required to change its running location (e.g. plat- 
form, site). The request must include the new location and can be per- 
formed while keeping its attached external state (go) or restating from a 
fresh default state (start). 

Replication A component (either composite or primitive) is replicated. Repli- 
cation operation is particularly targeted to composite components exhibit- 
ing the parametric replication of inner components (such as behaviour 
skeletons), and can be used to change their parallelism degree (and thus 
their performance and fault-tolerance properties). Replication events are 
further characterized with respect to their relation with replicated com- 
ponent state, if any. A component replica may be created with a fresh 
external state, carry a copy of the external state (copy), or share the 
external state with the source component (share). 

Kill A component is killed. Due to this kind of action disconnected components 
(and in particular storage managers) can subject to garbage collection. 

Described primitives make possible the implementation of several adaptation 
paradigms. In particular, migration may be used to adapt the application to 
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changes of grid topology as well as to performance drop of resources. Repli- 
cation and kill may be used to adapt both data and task parallel computa- 
tion. In particular, replication with share enables the redistribution of sub-task 
in data parallel computations; replication with copy enables hot-redundancy. 
Both stateful and stateless farm computation (parameter-sweeping, embarrass- 
ingly parallel) may be reshaped both in parallelism degree and location run by 
using replication and kill. 



Example 2.1 Let P, C, SF, S, AM, Wi, W 2 , W 3 components (Producer, Con- 
sumer, Stateful Farm 1 , Storage, Autonomic Manager, and Workers); h% ■ ■ ■ 
locations. Thee kinds of bindings are used in the assembly (see also Sec. 4)- 




-to— RPC or dataflow bindings management bindings > I c data sharing port bindings 



The described assembly of components (left) is paradigmatic of many producer- 
filter- consumer applications, where the producer (P) generates a stream of data 
and the filter is parallel component (SF) exhibiting a shared state among its 
inner components (e.g. a database). The original assembly (left) can be dynam- 
ically adapted (right) by way of two adaptation operations to react to run-time 
events, such as a request of increasing the throughput. The go operation moves 
Wi from L2 to L7 (as an example to move a component onto a more power- 
ful machine); the share operation that replicates W2 and place it in the new 
location hg (to increase the parallelism degree). Both operations preserve the 
external state of the migrated/replicated component, which is realised by way of 
a storage component) attached via a data sharing interface [3]. 

Example 2.1 illustrates how the management can be described from a global 
viewpoint. Indeed, the system is described by in a rather detailed way, e.g., 
components are explicitly enumerated along with their connections. Even if 
this global viewpoint is useful (and sometime unavoidable) when designing dis- 
tributed systems, it falls short in describing what single components are sup- 
posed to do when a reconfiguration is required. In other terms, it is hard to tell 
what the local behaviour of each component should be in order to obtain the 
reconfiguration described by the global view. 

Also, it is worth remarking that, though the diagram clearly describes the 
changes triggered by AM in this scenario, the lack of a formal semantics leaves 
some ambiguities. For example, it is not clear if the reconfiguration should take 
place if, and only if, the system is configured as on the lhs or this is rather a 

1 This component is a composite component, and in particular it is an instance of a be- 
havioural skeleton [1]. 
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"template" configuration (e.g., should the system reconfigure itself also when 
Wi is connected to W\ rather than to D? What if W2 was not present?). Of 
course, such ambiguous situations can be avoided when a formal semantics is 
adopted. 

3 A Walk through SHR 

Synchronised Hyperedge Replacement (SHR) can be thought of as a rule-based 
framework for modelling (various aspects of) of distributed computing [7] mod- 
elled as hypergraphs, a generalisation of graphs roughly representing (sets of) 
relations among nodes. While graphs represent (sets of) binary relations (la- 
belled arcs connect exactly two nodes) , labelled hyperedges (hereafter, edges) can 
connect any number of nodes. We give an informal albeit precise description 
of hypergraphs and SHR through a suitable graphical notation. The interested 
reader is referred to [7, 11] and references therein for the technical details. 

Example 3.1 In our graphical notation, a hypergraph is depicted as 




Edges (labelled by f, AM and a) are connected to nodes (g, I, V , s and s'). 
Specifically, AM connects g and I', f connects g, I' and s' while two a-labelled 
edges are attached to s and s' . Notice that nodes can be isolated (e.g., I). 

Hyperedges represent (distributed) components that interact through ports rep- 
resented by nodes. Connections between edges and nodes, called tentacles, allow 
components sharing ports to interact (e.g., in Example 3.1, / and AM can in- 
teract on g and on I'). 

Example 3.2 The hypergraph in Example 3.1 represents (part of) a system 
where a manager AM and a component f are located at I' and can interact on 
port g. The component f has access to the store at s' (e.g. by way of a data 
port [3]). In the system are also present another location I and store s. 

As in string grammars, SHR rewriting is driven by productions. In fact, 
strings can be rewritten according to a set of productions, i.e. rules of the 
form a — > j3, where a and (3 are strings (over fixed alphabets of terminal and 
non-terminal symbols). Similarly, in SHR hypergraph rewritings are specified 
by productions of the form L — > R, where the lhs L is a hyperedge, the rhs 
R is a hypergraphs and states that occurrences of L can be replaced with R. 
Intuitively, edges correspond to non-terminals and can be replaced with a hy- 
pergraph according to their productions. In SHR, hypergraphs are rewritten by 
synchronising productions, namely edge replacement is synchronised: to apply 
the productions of edges sharing nodes, some conditions must be fulfilled. More 
precisely, an SHR production can be represented as follows: 
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copy(s', s' 



I • 




rep(s') 



• S 




s 



where on the lhs is a decorated edge and on the rhs a hypergraph. The produc- 
tion above should be read as a rewriting rule specifying that edge / on the lhs 
can be replaced with the hypergraph on the rhs provided that the conditions on 
the tentacles are fulfilled. More precisely, copy and rep must be satisfied on 
node g and s, respectively while / is idle on node I, namely it does not pose any 
condition on I. According to our interpretation, this amounts to say that when 
component / is said to replicate with copy by its AM (condition copy on node 
g), it tells its store to duplicate itself (condition rep on node s). When such 
conditions are fulfilled, edge / is replaced with the hypergraph on the rhs which 
yield two instances of / one of which connected to the communicated nodes as 
prescribed by the rhs of the production. Indeed, / exposes three nodes on con- 
dition copy and one on rep; these represent nodes that are communicated (i.e., 
g and I are node communication accounts for mobility as edges can dynamically 
detach their tentacles from nodes and connect them elsewhere. 

SHR has a declarative flavour because programmers specify synchronization 
conditions of components independently from each other. Once the system is 
built (by opportunely connecting its components) it will evolve according to the 
possible synchronizations of the edges. Global transitions are obtained by paral- 
lel application of productions with "compatible" conditions where compatibility 
depends on the chosen synchronisation policy 2 . 

4 Productions for Non-functional Interfaces 

SHR can adequately formalise the non-functional interface mechanisms infor- 
mally described in Sec. 2. Three conceptually distinct interfaces can be consid- 
ered: i) interfaces between components and AM (for management bindings), ii) 
interfaces toward the external state (for data sharing bindings), and Hi) inter- 
faces for communicating with other components (for RPC/dataflow bindings). 
Since interfaces Hi are application dependent, we focus on the coordination- 
related interfaces i and ii. 

A main advantage of our approach is that all aspects of non-functional in- 
terfaces are captured in a uniform framework based on SHR. Indeed, 

• components are abstracted as edges connected to form a hypergraph; 

• the coordination interface of each component is separately declared and is 
not mingled with its computational activity; 

• being SHR a local rewriting mechanism, it is possible to specify confined 
re-configuration of systems triggered by local conditions; 

2 SHR is parametric with respect to the synchronisation mechanism adopted and can even 
encompass several synchronisation mechanisms [7, 11]. 
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Migration The migration of a component / is triggered when its AM raises 
a signal go with the new location on node g. The synchronisation of / on the 
go signal is given by following production: 




specifying that / running at I accepts to migrate to I' (lhs); the "location" 
tentacle of / is disconnected from I and attached to I' (rhs). Notice that / 
maintains the connection to the previous state s and I is still present. The 
tentacle connected to g on the lhs is connected to g' on the rhs; however, it 
might well be that g' = g (/ is still connected to the original AM) or g ^ g' (/ 
changes manager). Similarly start moves the component to a new location I'. 
However, a new external state a is created together with its attaching node: 




Replication Unlike migration, replication of / preserves its location: 



9 • 




the effect of the above production is to add a new instance of / at I' with AM 
connected to g'\ of course, I — I' and g = g' are possible. The newly generated 
instance shares external state with the original one. 

Replication can also activate the new instance with a different state: 




The production above creates a fresh replica of / at I' and assigns to it the 
manager at g'; notice that the two instances of / share the state s. 

Replication can also trigger a new instance of / that acts on a copy of the 
state original state as described in the production of page 5 where / must notify 
to its state to duplicate itself and connect the new copy on s' . Hence, the state 
connected to s duplicate itself on the node s' when the action complementary 
to rep is received, as stated below. 

rep< S '} • S | [tj] • S s ' • [ff] 
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Component killing Components are killed using the following production: 



9 • 



-kiii(>- 
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stating that / disappears when its corresponding AM sends a kill signal. 



5 Synchronizing productions 

The operational semantics of SHR is illustrated through an example that high- 
lights the following steps: 

1. individuate the adjacent tentacles labeled by compatible conditions; 

2. determine the synchronizing productions and replace the (instances of) 
edges on their lhs with the hypergraphs on their rhs; 

3. fuse the nodes that are equated by the synchronizations. 

Let us apply the previous steps to show how migration works in a situation 
represented by the following hypergraph 



startcr(g,Zi ,si) 



.9 • start<r{g',i',s')- 




where component / is running at I and shares g with a manager AM located 
at l\. For brevity, tentacles are decorated with the conditions triggering the 
rewriting (step 1). Indeed, the tentacles of AM and of / incident on node g 
yield compatible output and input conditions respectively so that AM orders / 
to migrate to l\ and to use the store at s\ while staying connected to g. 

Productions synchronisation consists in replacing the occurrences of the 
edges on the lhs with the hypergraphs specified in the rhs of the productions and 
applying the node fusions obtained by the node communicated. For instance, in 
the previous example the synchronising productions are the starter production 
of / given in Sec. 4 and the production of AM whose lhs and rhs consist of 
AM connected to g and l\ (step 2). Hence, after the synchronization, the node 
fusions g' = g, I' = l\ and s' — si are applied (step 3), so that the hypergraph 
is rewritten as 




Let us remark that I, a and s remains in the final hypergraph. In fact they 
should not be removed because other edges can be allocated on I or access a. 

The intuitive description of SHR given in this section suggests the following 
design style and execution style: 



8 



• assign an edge to each component and specify their productions; 

• represent the system as a hypergraph; 

• decorate the tentacles with the synchronisation conditions; 

• synchronize the productions until possible. 

It is worth remarking that, unlike other semantical frameworks (e.g., process 
calculi), in SHR synchronisation conditions may require more than two (pro- 
ductions of) components to be synchronised. This actually depends on the 
synchronisation policy at hand. For instance, in the migration rewriting de- 
scribed in this section, it is possible to use broadcast interactions on the node g 
so that all the components connected on g will move at V when the productions 
are synchronised. 

6 Conclusions 

The SHR is one of the modelling and theoretical frameworks of the Sensoria 
project [14]. SHR has been exploited in [6] for managing application level service 
level agreement (SLA) in a distributed environment; in [7] several variants of 
SHR have been described in a uniform context showing how this formalism can 
suitably tackle many programming and modelling facets of arising in service 
oriented computing. In this paper we have shown how SHR can be suitably 
used to formalise both adaption operations and the evolution of component- 
based autonomic applications. 

In an autonomic component model, as GCM, the AM relies on adaptation 
operation to realise its management policy (during the execution phase of the 
autonomic cycle). In general, a proper formalisation of adaptation operations 
(possibly involving the AM itself), may help 

• to develop correct and effective management policies providing the devel- 
oper with a precise description of the effect (semantics) adapation opera- 
tions; 

• to formally prove the propricrties of a single adaptations or sequences of 
them; 

• to formally prove local or global invariants characterising the evolution of 
assemblies of autonomic components; 

• to guide developers of the component model itself to establish the effective- 
ness of provided adaptation operations (e.g. the completeness of the set 
of operations with respect to a given planned evolution of the assembly) . 

This work covers the first of these items, thus represents a first step in this 
roadmap, whereas successive items can be enumerated in the future work. The 
presented adaptation operations are currently implemented in the reference im- 
plementation of GCM (developed within the GridCOMP STREP project [8]); 
their effectiveness in managing the QoS of grid applications is reported in [1]. 
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